REMARKS 



Status of Claims 

Claims 1, 7, 10, 13, 15, 22, 26, 30, 32 and 33 have been amended. Claims 1-10, 13-30 and 32-35 
are currently pending in the case. 

Amendments to the Claims 

Claims 1,13, 22, and 32 have been amended to clarify the claimed inventions. With respect to 
independent claims 1 and 22, amendments have been made to clarify that the approval parameters in 
those claims relate to the results of approval processing of purchase requests according to an entity's 
purchasing policies by one or more server systems. Similar limitations to those added to claims 1 and 22 
can be found in other claims, such as claims 2, 10, 24 and 30. In addition, the clarifying amendment 
from payment "identifier" to payment "card" is based upon limitations in dependent claims 7, 15, 26 and 
33. As such. Applicant respectfully requests that these claim amendments be entered, even though after 
final rejection, and that the amended claims be considered in the Advisory Action. 

Rejection of Claims 

Claims 1-10, 13-30 and 32-35 were rejected under §102 as anticipated by U.S. Patent No. 
6,226,624 (Watson). Applicant respectfully traverses these rejections. 

Initially, it is noted that the Office Action confuses transaction "authorization" processing and 
purchase request "approval" processing, which are two distinctly different processing operations. As 
used in Watson, transaction "authorization" is a process where a merchant seeks information from an 
authorizing agent about an account being used by a purchaser to make a transaction and where the 
merchant receives back an authorization code if the account is in good standing and the transaction is 
within the account parameters. How to handle this authorization process is the sole focus of Watson. In 
contrast, "approval" processing for purchase requests within an entity, as used with respect to the present 
invention, refers to a process where purchase requests within an entity are evaluated against that entity's 
purchasing policies to determine whether the purchase request is to be approved by the entity as an 
appropriate corporate expenditure. Once approved, the purchase request can then be fulfilled through a 
transaction that involves transaction "authorization" processing. Thus, transaction "authorization" 
processing is distinctly different from purchase request "approval" processing. 
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As stated above, Applicant has amended the claims to help clarify the claimed invention with 
respect to distinctions between "approval" processing of purchase requests within an entity and 
transaction "authorization" processing of merchant transaction authorization requests. 

The present invention is directed to "approval" processing according to purchasing policies of an 
entity in order to generate approval parameters according to the entity's purchasing policies. In addition, 
the present invention is directed to the use of these dynamic policy-based approval parameters in later 
payment processing of the actual vendor transaction. For example, as discussed in the Specification: 

Dynamic approval parameters for any particular purchase request are produced after applying the 
company purchase policies to those purchase requests within a purchasing management system. 
By utilizing dynamic approval parameters linked to specific purchase requests, as opposed to 
general static approval limitations available with existing purchasing cards, the systems and 
methods of the present invention allow for the efficient management and control of company 
purchases, regardless of where the purchase is made, without sacrificing the safety of having 
purchase requests reviewed under standard company purchase policies. 

[Specification, page 12 (emphasis added).] In short, although the payment processing aspects of the 
present invention relate to accepting (i.e., authorizing) or denying a merchant transaction request, the 
purchasing management aspects of the present invention relate to approval processing of purchase 
requests according to purchase policies of a company and how to tie the policy-related approval 
parameters that result from this approval processing to the later payment processing that is associated 
with the actual transaction at a vendor or merchant. 

Watson, in contrast, does not address approval processing according to company purchasing 
policies. Rather, Watson is focused solely on how to handle authorization and pre-authorization of the 
actual merchant transaction. In contrast with policy-based approval parameters of the present invention, 
therefore, the pre-authorization parameters of Watson are based solely upon actual or approximated 
quotes from a merchant. [Watson, cdl. 9, Ins. 5 1-60.] 

More particularly, Watson appears to discuss three basic transaction embodiments: (1) account 
user initiated purchases (FIGS. 2A-B), (2) account manager initiated purchases (FIGS. 6A-B), and (3) 
web user initiated purchases (FIGS. 8A-B). The first two embodiments appear to be directed to possible 
corporate environments where an account manager obtains a quote from a merchant and then the account 
user or the account manager initiates the purchase with the merchant, respectively. The last embodiment 
appears directed to individual consumers and is designed for the particular problem of consumer 
purchases of goods and services from Internet websites. 
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With respect to the first two embodiments of FIGS. 2A-B and 6A-B, Watson discloses systems 
and method for allowing an account manager to make pre-authorization requests for specific transactions 
through a computer connection to a card issuer. As described in Watson, during account set-up activities 
with the card issuer, certain categories of goods and services are designated with "pre-authorization 
SICs" that denote transaction categories for which pre-authorization will be required. [Watson, col. 5, 
Ins. 21-26.] The "pre-authorization transaction phase" then begins with an account manager 202 
generating a quote from a merchant for goods and services desired by an account user 204. [Watson, col. 
9, Ins. 47-60.] Based upon this merchant quote, the account manager 202 sends a pre-authorization 
request 224 to the card issuer 214, and the card issuer 214 then sends a pre-authorization request to an 
authorizing agent 212. [Watson, col. 9, Ins 60-64; col. 10, Ins. 28-33.] The authorizing agent 212 then 
stores pre-authorization parameters in a pre-authorization table 318. [Watson, col. 10., Ins. 33-37.] 
When the transaction is initiated at the merchant, the merchant sends a transaction authorization request, 
and the authorizing agent uses the pre-authorization table to process this request only if the transaction 
authorization request presents an SIC (standard industrial code) that has been previously designated as a 
pre-authorization SIC. [Watson, col. 6, Ins. 48-55; col. 10, Ins. 33-37.] 

With respect to the embodiment of FIGS. 8A-B, Watson discusses a web account user or 
consumer version of the system for purposes of Internet shopping. In particular, in this consumer 
version, a web account user or consumer 804 contacts a card issuer 814 to obtain a pre-authorization 
account or to designate pre-authorization SICs, engages in "traditional shopping or browsing" such as 
Internet shopping, determines the desirability of a web merchant's good or service, accesses an 
authorization web page 815, and enters specific parameters for the transaction through that web interface. 
[Watson, col. 17, In. 47 to col. 18, In. 19.] The authorization web page 815 then forwards a pre- 
authorization request to the authorizing agent 812. [Watson, col. 18, Ins. 16-19.] The authorizing agent 
then stores pre-authorization parameters in a pre-authorization table 918 associated with the consumer 
account. [Watson, col. 18, Ins. 43-59.] Following this pre-authorization phase, the web account user 804 
returns to the web merchant page 806 to consummate the transaction. [Watson, col. 18, Ins. 20-23.] Once 
the transaction is initiated at the merchant, the merchant sends a transaction authorization request, and 
the authorizing agent uses the pre-authorization table to process the transaction. [Watson, col. 18, Ins. 
27-32; col. 15, Ins. 58-61.] 
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As can be seen from these embodiments (FIGS. 2A-B, 6A-B and 8A-B), therefore, there is 
simply no teaching or suggestion in Watson to achieve or implement automated approval processing of 
electronic purchase requests according to an entity's purchasing policies in order to generate policy- 
based approval parameters that can be used for later payment processing thereby tying corporate 
purchasing policies to actual merchant transactions, as provided by the present invention. 

In relying upon Watson to reject the pending claims, therefore, the Office Action improperly 
equates or confuses "authorization" processing for merchant transaction authorization requests with 
"approval" processing for purchase requests according to an entity's purchasing policies within an 
entity's purchasing management system. 

For example, with respect to claim 1 , the Office Action points to pre-authorization requests from 
an account manager to a card issuer as an example of "a plurality of electronic purchase requests from 
requestors within an entity." [Office Action, page 3.] As stated above, pre-authorization requests relate 
to the processing ultimately to be done by the authorizing agent as part of the final merchant transaction 
and are not purchase requests from within an entity. Again with respect to claim 1, the Office Action 
points to the pre-authorization request and associated account number as meeting the step of "evaluating 
the plurality of purchase requests with respect to an entity's purchase policies utilizing one or more 
server systems." [Office Action, page 3.] As stated above, this information relates to "authorization" 
processing, and Watson provides no teaching with respect to "approval" processing. In Watson, there is 
no discussion of an entity's purchasing policies, no discussion of evaluating purchase requests based 
upon those purchasing policies, and no discussion of generating approval parameters based upon this 
approval processing as part of a purchasing management system within an entity. Still further, the Office 
Action equates the pre-authorization parameters of Watson with the step of "generating a plurality of sets 
of approval parameters utilizing one or more server systems." [Office Action, page 3.] Although the 
approval parameters of the claimed invention are subsequently used for transaction processing by a 
payment processing system, these approval parameters are based upon the results of approval processing 
according to an entity's purchase policies. In contrast, the pre-authorization parameters of Watson are 
based solely upon actual or approximated quotes from a merchant. [Watson, col. 9, Ins. 51-60.] 

Continuing on to dependent claim 2, the Office Action points to the account manager and a 
computer connected to the card issuer as meeting limitations directed to providing network access to 
purchasing management rules, receiving purchase requests, and applying the purchasing management 
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rules to generate the approval parameters. [Office Action, page 4.] This argument in the Office Action 
again confuses transaction "authorization" processing as part of a merchant transaction with "approval" 
processing of purchase requests according to an entity's purchasing policies. As stated above, 
authorization and pre-authorization, as used in Watson, refer to the acceptance or denial of an actual 
transaction authorization request from a merchant. [Watson, col. 8, Ins. 36-41.] What Watson does not 
discuss is approval processing of purchase requests within an entity according to an entity's purchasing 
policies as would occur within the purchasing management system 100 of the present invention. 

With respect to claim 3, the Office Action points to an authorizing agent who receives 
authorization requests from a merchant in Watson as "an approver" within a purchasing management 
system. [Office Action, pages 4-5.] Again, the authorizing agent of Watson acts to authorize or deny an 
actual merchant transaction. In contrast, the approval processing in the presently claimed invention 
addresses automated approval processing of a purchase request according to an entity's purchasing 
policies. Payment processing of the actual transaction would occur at a later time based upon these 
policy-based approval parameters. 

Looking to independent claim 10, the Office Action relies upon the pre-authorization parameters 
communicated by the account manager to the card issuer and upon the authorization request from a 
merchant transaction as meeting the limitations of the claim. [Office Action, page 6.] As stated above, 
however, the "approval" processing limitations addressed in claim 10 are simply not met or even 
addressed by the systems described in Watson that focus solely on "pre-authorization" and 
"authorization" of merchant transactions. This confusion between transaction "authorization" and 
purchase request "approval" processing continues with respect to the claims that depend from claim 10. 

Independent claims 22 and 32, which are not individually addressed in the Office Action, require 
similar "approval" processing related limitations to those in independent claims 1 and 10. And claims 
that depend from claims 22 and 32 further include approval processing related limitations. 

In short, Watson does not teach or address purchase request approval processing according to 
purchase policies of an entity as part of a purchasing management system, does not address the creation 
of approval parameters according to an entity's purchasing policies as part of this approval processing, 
and does not address the later use of these policy-based approval parameters for payment processing. In 
contrast, the claimed invention requires purchase request approval processing according to purchasing 
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policies of an entity as part of a purchasing management system for the entity. This automated approval 
processing leads to creation of approval parameters according to the entity's purchasing policies. And it 
is these policy-based approval parameters created through approval processing that are later utilized by a 
payment processing system to accept (i.e., authorize) or deny a merchant transaction. 

Based upon the above reasons, therefore, Applicant respectfully asserts that Watson does not 
teach or suggest the presently claimed inventions. Removal of the pending rejections and an indication 
of allowability for the pending claims are respectfully requested. 



Conclusion 

Applicant respectfully asserts that the pending claims are in condition for allowance. 
Reconsideration of the application is respectfully requested. 



The Examiner is invited to contact the undersigned at the phone number indicated below with 
any questions or comments or to otherwise facilitate expeditious and compact prosecution of the 
application. 



Respectfully submitted, 

^■©fian W. Peterman 
Reg. No. 37,908 
Attorney for Applicant 

O-KEEFE, EGAN & PETERMAN 
1101 Capital of Texas Highway South 
Building C, Suite 200 
Austin, Texas 78746 
(512) 347-1611 
FAX: (512) 347-1615 
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